Developer's mind

solId
ISP
interface segregation principle
принцип разделения интерфейсов заключается в том, что лучше иметь более узкоспециализированные интерфейсы и уже через их имплементацию реализовывать определенное поведение у конкретных классов. Разумеется смысл тут в генерации низкосвязанного кода - когда методы и модули зависимы не от больших объектов и интерфейсов, а именно от узких интерфейсов. Наверное один из самых ярких примеров - это Iterable или Comparable в базовой поставке Java. Только представьте, насколько менее удобно было бы использовать циклы или методы сравнения, будь они основаны на более толстых интерфейсах или даже отдельных реализациях. Например, насколько сложнее стала бы наша жизнь при необходимости использовать в циклах только наследников класса Collection.
Любопытная деталь в том, что мы достаточно редко анализируем альтернативно возможные реализации нашего кода/модуля потому что в целом мы всегда можем справиться с архитектурными недостатками. Но стоит один раз переписать модуль сделав акцент на ISP как становятся понятны плюсы. Особенно если мы хотим вынести кусок модуля в виде библиотеки. Именно в процессах, критичных к низкой связности, и чувствуется огромный потенциал подходов основанных на правильном использовании интерфейсов.

Только не нужно уходить в крайности. Я встречал очень много проектов с пунктиком по поводу использования интерфейсов, но их неправильное использование ничего кроме боли не приносит

www.tg-me.com/jp/Developer& 39;s mind/com.developers_mind/21

314 viewsSep 18, 2020 at 08:48

solId
ISP
interface segregation principle
принцип разделения интерфейсов заключается в том, что лучше иметь более узкоспециализированные интерфейсы и уже через их имплементацию реализовывать определенное поведение у конкретных классов. Разумеется смысл тут в генерации низкосвязанного кода - когда методы и модули зависимы не от больших объектов и интерфейсов, а именно от узких интерфейсов. Наверное один из самых ярких примеров - это Iterable или Comparable в базовой поставке Java. Только представьте, насколько менее удобно было бы использовать циклы или методы сравнения, будь они основаны на более толстых интерфейсах или даже отдельных реализациях. Например, насколько сложнее стала бы наша жизнь при необходимости использовать в циклах только наследников класса Collection.
Любопытная деталь в том, что мы достаточно редко анализируем альтернативно возможные реализации нашего кода/модуля потому что в целом мы всегда можем справиться с архитектурными недостатками. Но стоит один раз переписать модуль сделав акцент на ISP как становятся понятны плюсы. Особенно если мы хотим вынести кусок модуля в виде библиотеки. Именно в процессах, критичных к низкой связности, и чувствуется огромный потенциал подходов основанных на правильном использовании интерфейсов.

Только не нужно уходить в крайности. Я встречал очень много проектов с пунктиком по поводу использования интерфейсов, но их неправильное использование ничего кроме боли не приносит

BY Developer's mind